1. Technical Field
The present invention relates to an improved data processing system. In particular, the present invention relates to generating a service data object based service pattern for a J2EE Enterprise JavaBeans™ model in a data processing system. Still more particularly, the present invention relates to dynamically generating a service data object based service pattern for the J2EE Enterprise JavaBeans™ model by defining one or more service data objects for any container-managed persistent entity bean and generating a session façade bean that includes methods for operating on a data object graph.
2. Description of Related Art
In most enterprise application development environments, developers often use enterprise JavaBeans™ objects for modeling interactions between components and for managing data persistence in their applications. J2EE Enterprise JavaBeans™ is a specification available from Sun Microsystems, Inc. Examples of enterprise JavaBeans™ (EJB) objects include ‘Entity’ beans and ‘Session’ beans. Entity beans model the persistent data used by the EJB application and application clients. An Entity bean is a type of enterprise JavaBeans™ that persists data in a data source beyond the lifetime of the client application. Session beans are designed to execute a given task as requested by clients of the EJB interfaces. Often Session beans themselves are used to interact with the modeled Entity beans to perform some business logic.
However, the use of business objects introduces disadvantages, such as tight coupling between business components and data source implementation. This tight coupling makes it difficult to migrate client applications from one type of data source to another. Thus, business objects have to be updated to handle the new type of data source. Another problem is that it is not possible to operate on the data retrieved by an entity bean in a disconnected fashion since so many changes can be made and the updates could be performed in one transaction.
One solution to alleviate these problems is the use of data access objects to abstract and encapsulate all access to the data source. Data access objects (DAOs) hide implementation details from the client application. DAOs are transfer objects that return data and associated attribute values from the data source, such that the number of remote calls to the data source is minimized. DAOs also isolate client applications from the data store by providing disconnected access to persistent data. Furthermore, DAOs allow for defining “projections”, of the underlying Entity EJBs. That is, the DAOs can represent “lightweight” objects comprised of a subset of the fields from the Entity beans, thus reducing the amount of data to be transferred in a remote call.
This solution meets the need of most small client applications. However, as the complexity of client applications and interactions between business objects increase, the use of data access objects is not by itself sufficient. Therefore, another solution, known as session bean façade, is introduced.
Session bean façade provides a single interface to client applications by hiding all complex interactions between business objects. Session bean façade not only manages relationships between business objects, it also manages life cycles of business objects by creating, locating, modifying, and deleting them as required by the workflow of the client applications.
Session bean façade provides a course grained method, or service, instead of exposing all the business objects or entity beans, to perform the required business function. For example, instead of directly invoking a getAddress method of the Employee class, a client application may invoke a getEmployeeAddress method in the session bean façade that invokes the getAddress method of the Employee class. Thus, knowledge of underlying business objects or business logic is not required for the client applications.
When the relationship between business components changes, new DAOs are defined and created. With the session bean façade, modification to the business objects or entity beans is necessary in order to include these newly created DAOs and methods for transfer of data. This modification affects the interface of the entity bean each time a new DAO is created, because the remote interface and the entity bean will have to be modified to include access specific code.
In addition, current implementations of the session bean façade only allow one entity bean definition per façade, which increases the number of façade definitions required. Thus, each time a DAO is updated, the client has to make a separate query to the session bean to update each DAO that is affected. This affects bandwidth performance, since each time the entity bean is modified, the entity bean is sent over the wire to the session bean façade. It is also expensive to serialize the entity bean for transfer between the client and the session bean façade.
Furthermore, no relationship attributes are currently maintained in the DAO to define relationships between entity beans. There is no synchronization of values of related DAOs. Thus, when one DAO is updated, the client has to make separate calls to update the related DAOs. Moreover, retrieving and loading of data in a data store is currently handled by the entity bean itself in the session bean façade.
Thus, a new type of data objects, known as service data objects (SDOs), is developed to address the deficiencies of DAOs. According to the service data object specification, available from International Business Machines Corporation and BEA Systems, herein incorporated by reference, service data objects (SDOs) are composed of data objects, which represent the data itself, and data graphs, which act as an envelope for data objects and track changes to the data objects. While SDOs have the advantage of persisting changes of data objects to a data source, no mechanism currently exists that takes advantage of SDOs in an EJB model to reflects changes in the entity beans. It is possible, in accordance with the SDO specification, to implement an “EJB Mediator”, as is available in IBM WebSphere Application Server version 6.0.
Therefore, it would be advantageous to have an improved method and apparatus that generates a service data object (SDO) based service pattern for an enterprise JavaBeans™ model, such that relationships between SDOs are maintained.